Problem

When using gog auth add with a client alias for an account whose email has a subdomain (e.g. user@sub.company.ai), auth fails with:

authorized as user@sub.company.ai, expected company.ai

This affects any Google Workspace account on a subdomain domain (e.g. baher@medicus.ai using client alias baher.ai). Two bugs combine to cause this:

1. auth_add.go: The OAuth-authorized email is compared against the alias name, which never matches a bare client name, so the token is never saved.
2. clients.go: ResolveClientForAccount treats any input without @ as a malformed email with no domain, falling through to DefaultClientName instead of treating it as a direct client name.

Fix

• auth_add.go: Skip the email match check when c.Email has no @ — the caller is intentionally using a client alias, not an email address.
• clients.go: Treat any input without @ as a direct client name rather than attempting email/domain parsing.

Usage after fix

# One-time setup in config.json:
# { "account_clients": { "user@sub.company.ai": "company.ai" } }

gog auth add company.ai --services gmail,calendar,drive,...
# sign in as user@sub.company.ai in the browser

gog gmail search "newer_than:1d" --account user@sub.company.ai  # works

Tests

Added two new test cases:

• TestAuthAddCmd_ClientAliasSkipsEmailCheck — verifies auth succeeds when a client alias is passed
• ResolveClientForAccount/client name without @ is used as-is — verifies bare client name is returned directly
• ResolveClientForAccount/subdomain email routes via account_clients mapping — verifies subdomain email routing via config

All existing tests pass.